All of these changes look good for request/response based reports, but event based reports would not get these new values, or any values set in applyFragmentData for that matter. Ideally these fields would be set via reporter.update so that the values would persist for all reports. However, this would be a much larger change because the persistent values would need to be properly flagged with object type tokens. For now, I think this work leaves the feature in a better place than it was, so we can merge it.

I've been playing around with how we could workaround this and enable these keys in event mode, and here's an implementation I've been drafting for this PR:

Persists those keys in the reporter's shared state via reporter.update(), so they are automatically included in all subsequent reports — including event reports.

Each key is updated from the hls.js event that provides the most accurate context for it:

• pb and rtp — updated on FRAG_CHANGED, which provides the fragment and its level directly. The object type token (ot) is also persisted here since fragment context is available.
• lb and tpb — updated on LEVELS_UPDATED (initial manifest load) and MAX_AUTO_LEVEL_UPDATED (ABR cap changes), using the existing getLowestBandwidth / getTopBandwidth helpers (made optional-fragment to support this call site). These updates intentionally omit ot — without a stable fragment reference, persisting a potentially stale object type would be worse than omitting it.
• dl — updated on BUFFER_APPENDED / BUFFER_FLUSHED alongside the existing bl update, using the current buffer length and playback rate.

The behavior of request reports is unchanged — applyFragmentData still computes all values with full per-request context, which remains the most precise snapshot at request time.

Known limitations (pre-existing or inherent to the approach):

• tpb reflects maxAutoLevel (a bandwidth cap) rather than a true device capability cap, consistent with the existing request-report implementation.
• dl may be slightly stale if playbackRate changes between buffer events.
• lb/tpb event reports do not carry ot; a fully scoped solution would require per-object-type persistent state in the reporter, which is a larger refactor.

All comments have been addressed 😄. Let me know if there's anything else we can improve. We can also discuss the feasibility of enabling these keys for event reports on this PR

Following up on the known limitation around event-mode reports, I've been thinking about a scoped approach that could resolve it without the larger per-object-type refactor.

The idea is to gate all reporter.update() calls for rtp, lb, pb, tpb, and dl behind a muxed-stream check. When the active level has no separate audio group, ot=av is stable and unambiguous for the lifetime of that level and there is no risk of persisting a stale object type. In that case, we can safely include ot in every update() call, which means event-mode reports would get the full picture.

For non-muxed streams (alternate audio renditions), we'd skip the update entirely rather than report without ot or risk mixing up audio and video buffers. This sidesteps the per-object-type persistent state problem at the cost of not supporting those keys in event mode for non-muxed content , which seems like a reasonable trade-off for now.

Wanted to float this before going further, does this direction seem good to you?

We still wouldn't want to include ot on the update calls because it doesn't have the same meaning in event reports. Instead you would use the parameterized value for the mixed buffer length, and produce values like br=(1000;av). Looking at this further, all of the buffer related fields should also be parameterized. It might be worth a separate issue to address all the parameterized fields at once (bitrate and buffer).